이번 3차 스프린트 기간 동안 Production 서버를 구축하면서, 몇 가지 고민해야 할 사항이 있었다.
그래서 백엔드 팀원들과 인프라 구조를 어떻게 개선할지에 대해 논의를 했다.
application.yml에 들어갈 민감 데이터를 어떻게 관리할 것인지에 대한 논의
현재 우리 서비스는 MySQL 서버 접속을 위한 사용자명과 비밀번호, Github 연동 로그인에 필요한 Oauth 시크릿 키, 토큰 생성을 위한 시크릿 키, 파이어베이스 연동을 위한 프로젝트 id 등 외부에 노출되면 위험할 수 있는 정보가 꽤 있다.
지금의 방식은 배포용 application.yml 파일을 서버에 직접 저장하고, 배포 때마다 application.yml 파일을 덮어씌우는 방법인데 너무 주먹구구식이고 관리하기 불편하다는 단점이 있어서, 이런 데이터를 어떻게 관리하면 좋을지 논의한 결과 다음 세 가지의 대안이 나왔다.
-
Github Secret으로 저장하기
저장된 값을 확인할 수 없어서 유지 보수가 어렵다는 단점이 있다.
-
jasypt로 민감 데이터를 암호화하기
이 경우 키값은 Github secret으로 저장하는 것이 되겠다.
암호화되었지만 외부에 노출된다는 것은 그대로.
-
서브 모듈 사용하기
private repository에 민감 정보를 저장하고, github actions를 돌릴 때 불러오도록 하기.
⇒채택
이 중 서브 모듈을 사용해본 적이 없어 한 번 사용해보고 싶기도 했고, 다른 방법에 비해 단점이 두드러지지 않아 서브 모듈을 사용해서 민감 정보를 관리하기로 결정했다.
배포 과정에서 서버로 보내기 전 Jar파일을 어떻게 보관할 것인지
우리 팀은 자동 배포 툴로 Github Actions를 사용하고 있다.
프로젝트를 빌드하는 과정에서 너무 많은 용량을 요구하기 때문에, 운영/개발 서버에서 프로젝트를 직접 빌드하지 않고 Github 클라우드 서버에서 빌드한 뒤 jar파일을 추출하여 운영/개발 서버에 전송하는 식으로 배포 자동화를 구축했다.
이 때 jar 파일을 Github Actions Artifact로 만들어 올리고, 운영/개발 서버의 Actions Runner가 해당 Artifact를 내려받는 식으로 구현했었다.
하지만 이 방식은 프로젝트 레포지토리의 collaborator로 설정된 사람들이라면 제약없이 우리 프로젝트의 jar 파일을 내려받을 수 있다는, 보안적으로 치명적인 문제가 있었다. 즉 우테코 크루들이 우리의 jar 파일을 모두 뜯어볼 수 있다는 것이다.
그래서 jar 파일을 Artifact 대신 Docker Image로 만들어 Docker Hub의 private Repository로 올리고 서버에서 내려받는 방법을 사용하기로 하였다.